Introduction

Every testing cycle starts in the same place: understanding what you are supposed to test. Before you write a single test case or execute a single step, you need to know the requirements, and you need a system to track your work.

This reading explains how requirements flow into a testing environment, what makes a well-structured test case, and how Jira Cloud and Zephyr work together to keep your testing organized and traceable.

From Requirements to a Jira Backlog

If you are new to these tools, do not worry; this reading explains each one as you go.

GreenLeaf Grocers is a mock e-commerce storefront built specifically for this capstone experience. It simulates a real-world online grocery checkout flow complete with a product catalog, promo code functionality, and a connected database, giving you a realistic environment to practice against. Think of it as your first client: a live-feeling application with real defects waiting to be found.

To get started, you will download the GreenLeaf_Backlog.csv file—a pre-seeded backlog containing the Checkout Overhaul Epic and three User Stories—and import it directly into your Jira Cloud workspace.

In professional QA, requirements rarely arrive as a polished, ready-to-test document. They typically come in as User Stories : short, goal-oriented descriptions of what a feature should do from the perspective of the person using it. User Stories are often vague, and part of your job as a QA Tester is to ask the right questions to fill in the gaps.

In Jira Cloud , work is organized hierarchically. An Epic represents a large body of work—in this case, the GreenLeaf Grocers Checkout Overhaul. Beneath the Epic sit individual User Stories that break that work into testable chunks. Importing a backlog CSV (Comma-Separated Values file) is a common way to populate a Jira board quickly when a project is being set up for the first time.

Once your backlog is imported, your Jira board gives you a visual overview of all the work in the pipeline. This is the single source of truth for your testing effort—everything you design, execute, and report will trace back to items on this board.

What Makes a Good Test Case

A test case is a documented set of conditions and steps used to verify that a specific piece of functionality behaves as expected. It is not the same as a test script (which is automated) or a bug report (which documents a failure). A test case defines the intent of the check before any execution happens.

In Zephyr , the test management extension inside Jira, each test case is linked directly to a User Story. This linkage is critical. It means every test you run can be traced back to a requirement, and every defect you find can be traced back to a test. That traceability is what makes your work auditable and professional.

A well-structured test case includes:

Authoring three distinct test cases for the Checkout Epic means covering three different behaviors or scenarios. Strong test design avoids duplication; each case should test something the others do not.

Linking Test Cases to User Stories

The connection between a Zephyr test case and its parent Jira User Story is not just organizational; it is a professional standard. When a defect is found during execution, the linked test case tells the development team exactly which requirement was violated. When a test passes, the linked story moves closer to being marked complete.

This traceability also feeds directly into your portfolio. A screenshot of your Jira board showing an organized Epic with linked User Stories, alongside a Zephyr view showing authored test cases, communicates to any hiring manager that you understand how QA fits into a real development workflow, not just how to run tests in isolation.

Conclusion

Requirements analysis and test case design are the foundation of every testing cycle. Getting this phase right—importing your backlog cleanly, reviewing User Stories critically, and authoring traceable test cases in Zephyr—sets up every step that follows for success.